【第2922期】对于质量保障，前端职能该做些什么？

前言

各公司各项目的流程怎么做才比较有意思。今日前端早读课文章由 @严选技术分享，公号：严选技术产品团队授权。

正文从这开始～～

对于前端项目交付的质量，各团队往往会建设众多的交付标准，希望以此来约束项目的开发，从而保障最终的交付物质量。

1. 背景

对于前端项目交付的质量，各团队往往会建设众多的交付标准，希望以此来约束项目的开发，从而保障最终的交付物质量。

严选也不例外，于先前制定了前端项目验收标准，但在实行期间，遇到以下问题：

• 前端团队构成复杂且业务线众多，并且存在较多的项目外包，人员质量参差不齐。

• 指标化的交付标准靠规范无法进一步的提升，且指标的维持需要依靠于人为把握，无法严格控制到位。

为保障前端项目验收标准在业务中的落地，从而保证前端项目的在线质量，计划从以下两个手段出发：

• 工具化：提供各类检测工具，用于交付物的检测（如性能检测工具、错误检测工具、容灾检测工具等）。

• 流程化：穿插到前端的核心研发流程中，实现通过、告警、阻断三种策略，进行自动化验收。

2. 分析

重新审视整个前端的项目周期，前端团队内一般会建设以下的质量保障体系：

1、需求评审

• 需求前准备，获取需求链接，需求稿等信息

• 项目负责人必须参会，明确需求范围和需求内容

2、技术方案阶段

• 依据《前端技术方案模板》输出前端技术方案

3、项目开发阶段

• 前端体系知识库

• 本地开发工程体系

4、项目提测、测试阶段

• review 机制

5、项目发布

• 线上环境监控

可以看到主要的交付物质量保障是在本地开发工程体系和 review 机制中，而 review 机制是相对脆弱、不可靠的，我们追求使用流程 / 工具化的方式来替代掉这部分，新的质量保障体系如下：

1、需求评审

• 需求前准备，获取需求链接，需求稿等信息

• 项目负责人必须参会，明确需求范围和需求内容

2、技术方案阶段

• 依据《前端技术方案模板》输出前端技术方案

3、项目开发阶段

• 前端体系知识库

• 本地开发工程体系 -> 前端自动化测试工具 -> 关联提测卡点

4、项目提测、测试阶段

• 前端技术方案 -> 关联提测卡点

• 前端自动化测试工具

5、项目发布

• 前端自动化测试工具 -> 关联发布卡点

• 前端自动化测试工具 - 巡检

• 线上环境监控

因此体系的重点在于前端自动化测试工具和 devOps 流程关联这两个事项上。

2.1 前端自动化测试工具

有句话说的好，要想改进它，必须度量它。因此测试工具的核心就是将相关的检查项指标化，由具体的数值来判定交付物是否合格。

根据测试的内容不同，这里可以分为两类：

• 针对工程代码的静态检查：围绕的是代码本身的静态测试

• 针对部署产物的检查：围绕的是部署后的页面内容测试

2.1.1 针对工程代码的静态检查

一般前端工程中都会使用 eslint、commitlint、commentslint 等工具进行检查，这类的工具一般规则都比较统一，常常内置在工程中。而对于业务性质的代码检查，这部分就不够适用了，比如严选 B 端工程中 sharkrForm 的覆盖率检查，是基于静态代码的检查，可以结合项目本身打包时的 AST 期间，扩展相关插件完成。

2.1.2 针对部署产物的检查

代码只是交付物的中间产物，最终的交付物往往都是页面，因此对于页面的检查是非常必要的。

对于业务逻辑功能本身，我们全权依托并相信 QA 同学，但对于页面本身的质量，前端自动化测试工具可以做不限于以下内容的检查：

• 性能测试

• 错误检测

• 容灾（白屏）检测

对于页面的访问测试，通过 puppeteer 工具可以非常方便的来完成，其中不同的用户身份访问页面，这部分的能力建设值得关注。

2.1.3 性能测试

性能这个事项之前文章有过介绍，感兴趣的同学可以了解下《如何从零开始做性能优化》，性能检测的核心还是在于指标化和量化，这里采用 FMP 的最大值和均值来作为考核项。

2.1.4 错误检测

大家往往聚焦在页面内容展示的检查，往往会忽略 console 中的错误，而这类错误有些时候是不可容忍的。

错误可以简单的分为 2 个大类：语法错误和资源错误，语法错误我们可以通过代码注入监听，对于资源错误则可以采用 puppeteer 的 response 监听就可完成。

2.1.5 容灾（白屏）检测

在大流量情况下，服务出现限流或者异常时，前端页面展示白屏是不能接受的，因此前端自动化检测工具集成了自动化的容灾能力测试。

功能的核心可以简单的归纳为以下三个点：

• 自动化获取页面内的请求列表；

• 创建每个请求异常（拦截 / 异常响应码）的测试访问用例

• 检测每个用例后页面是否白屏

2.2 devOps 流程关联

建设完工具能力之后，就应该关联到 devOps 流程中，在提测和发布两大卡点中，实现通过、告警、阻断三种策略，进行自动化验收。

2.2.1 提测卡点

对于工程代码的静态检查，我们可以在 CI 阶段进行工具测试，同时上报检查结果，并在项目全流程管理平台中，在项目的提测卡点关联此检查项，对于未通过工具检查的项目拒绝提测。

2.2.2 发布卡点

对于部署产物的检查，我们需要找到制品部署完成后的节点（注意：这里不是指 git 中 pipeline 完成的时间点）。

通常在我们的 devOps 中，会有以下两个规则：

• 测试制品部署测试环境时，是自动的；

• 在部署线上制品到线上环境前，会将线上制品部署到测试环境进行回归验证，验证完成后通过手动的方式进行线上发布；

我们可以在规则二中，在线上制品部署测试环境时，进行部署产物的自动化检查，在线上发布时进行卡点，对于未通过工具检查的项目拒绝线上发布。

ps：发布卡点往往比较靠后，在测试制品在测试环境部署后，虽然不能进行测试环境的发布卡点（因为是自动完成），但也可以执行部署产物的自动化检查，通过告警的方式，让对应开发提前感知，并进行相关问题的修复。

3. 总结

以上，我们可以将部分人工的操作以工具化、流程化的方式来替换，聚焦在工具能力的建设，从而形成一套更高效的项目验收流程。

3.1 严选中的最佳实践

在严选业务中，对于常规业务的验收均能采用上述流程，对于有差异的页面搭建体系中的页面发布流程也提供了解决方案。

3.1.1 特殊场景兼容

3.1.1.1 页面搭建体系中的页面搭建

页面由平台搭建生成，由运营 / BU / 产品等角色搭建，无完整的 devOps 流程，这类页面则是通过自动巡检的方式，由定时任务触发，对最新创建的页面执行自动化检查，并将结果直接同步搭建业务大群，方便对应业务快速发现问题并解决。

3.1.1.2 页面搭建体系中的页面开发

对于页面搭建体系中的页面开发流程，底层沿用页面搭建发布流程，不同于一般流程，线上的发布也是自动的，不同的点在于并不会直接对当前产物进行投放，而是通过投放平台，因此可以在投放平台添加投放卡点进行拦截验证。

3.1.2 新的验收标准

有了一套更高效的项目验收流程后，对于外包类的项目，我们可以建设更指标化的验收标准，通过对每个项目自动打分的方式，用来评判更好地评判项目的交付物质量，从而对这次外包项目进行奖惩。

可参考的验收标准如下（采用扣分制，默认 100 分）：

1、需求评审

• 项目负责人必须到场【考核，签到情况检查】

2、技术方案阶段

• 项目技术方案输出【考核，方案内容自动检查】

3、项目开发阶段

• 代码规范（eslint、commitlint、commentslint 等）

• 页面交互【可申请额外加分】

4、项目提测、测试阶段

• 冒烟通过率【考核】

• 提测时间【考核，自动化测试工具已关联卡点，可放大此项】

5、项目发布

• 上线时间【考核，自动化测试工具已关联卡点，可放大此项】

4. 说在最后

对于项目外包，我们不能简单的将项目完全托付给外包团队，项目交付物的质量仍然是团队应该重点关注的内容，最终的质量应该是由团队进行负责。

当然，对于和外包团队边界处理中，更建议团队前期去建设更自动更完善的验收标准，提升最终交付物的质量，以减少不必要的精力和资源消耗。

5. 参考资料

• puppeteer doc：https://pptr.dev/api/puppeteer.puppeteernode

• 如何做前端异常监控：https://www.zhihu.com/question/29953354

• 聊聊前端监控 —— 错误监控篇：https://juejin.cn/post/6867773840768909326

• Eslint + Prettier + Husky + Commitlint+ Lint-staged 规范前端工程代码规范：https://juejin.cn/post/7038143752036155428

关于本文
作者：@严选技术
原文：https://mp.weixin.qq.com/s/jUZ0JODm4m49sY8tDZPGCg

这期前端早读课
对你有帮助，帮” 赞 “一下，
期待下一期，帮” 在看” 一下 。